Cross-domain brokering protocol cloud proxy

ABSTRACT

Aspects described herein provide improved system architectures for a cross-domain proxy so that server/controller software may be placed in a cloud-based environment, with only limited equipment required on-premises at a user location for use by application client software. Aspects described herein provide techniques for communicating information between disparate domains, while each party to the transaction believes it is on the same domain as the other party to the transaction. Aspects described herein generally relate to a method to transparently transport the Citrix Brokering Protocol (CBP, or other protocols) between On-Premises VDAs (e.g., virtualized Windows computers) to an In-Cloud Broker running on the Desktop Delivery Controllers (DDCs) when each resides in different domains. Using aspects described herein, resources that otherwise need to be co-located on the same administrative domain can be moved to different domains, e.g., using a cloud-based system architecture.

CROSS-REFERENCE TO RELATED CASES

This application is a continuation of application Ser. No. 15/146,131,filed May 4, 2016, which claims priority to provisional application no.62/158,598, filed May 8, 2015, having the same title, and which isherein incorporated by reference.

FIELD

Aspects described herein generally relate to a method to transparentlytransport the Citrix Brokering Protocol (CBP, or other protocols)between On-Premises VDAs (e.g., virtualized Windows computers) to anIn-Cloud Broker running on the Desktop Delivery Controllers (DDCs) wheneach resides in different domains.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of aspects described herein and theadvantages thereof may be acquired by referring to the followingdescription in consideration of the accompanying drawings, in which likereference numbers indicate like features, and wherein:

FIG. 1 depicts an illustrative computer system architecture that may beused in accordance with one or more illustrative aspects describedherein.

FIG. 2 depicts an illustrative remote-access system architecture thatmay be used in accordance with one or more illustrative aspectsdescribed herein.

FIG. 3 depicts an illustrative virtualized (hypervisor) systemarchitecture that may be used in accordance with one or moreillustrative aspects described herein.

FIG. 4 depicts an illustrative cloud-based system architecture that maybe used in accordance with one or more illustrative aspects describedherein.

FIG. 5 shows a conventional system architecture of a prior art system.

FIG. 6 shows an illustrative system architecture according to one ormore aspects described herein.

FIGS. 7-9 shows illustrative source code that may be used to implementone or more features described herein.

FIG. 10 illustrates a detailed view of a portion of the architectureshown in FIG. 6.

DETAILED DESCRIPTION

In the following description of the various embodiments, reference ismade to the accompanying drawings identified above and which form a parthereof, and in which is shown by way of illustration various embodimentsin which aspects described herein may be practiced. It is to beunderstood that other embodiments may be utilized and structural andfunctional modifications may be made without departing from the scopedescribed herein. Various aspects are capable of other embodiments andof being practiced or being carried out in various different ways.

As a general introduction to the subject matter described in more detailbelow, aspects described herein are directed towards improving uponprior art system architectures where all virtualized desktopapplications (VDAs), desktop delivery controllers (DDCs), and theprimary domain controller (PDC) are resident on-premises at a user'slocation. Because all resources are located at the user location, eachuser/location incurs significant cost associated with purchasinghardware and software resources, as well as employee time and salary tomaintain the system. Aspects described herein provide improved systemarchitectures for a cross-domain proxy so that the DDCs may be placed ina cloud-based environment, with only limited equipment requiredon-premises at a user location. Customers and users can realizesignificant cost savings by moving DDCs to a cloud-based system usingeconomies of scale realized by cloud-architectures. However, because ofinherent security measures enforced by each system's primary domaincontroller (PDC), the move is not as simple as just installing thesoftware in a different location. Rather, each DDC and VDA expect to beinstalled on the same primary domain to ensure that necessary securitymeasures are enforced. As a result, aspects described herein providetechniques for communicating information between disparate domains,while each party to the transaction believes it is on the same domain asthe other party to the transaction.

It is to be understood that the phraseology and terminology used hereinare for the purpose of description and should not be regarded aslimiting. Rather, the phrases and terms used herein are to be giventheir broadest interpretation and meaning. The use of “including” and“comprising” and variations thereof is meant to encompass the itemslisted thereafter and equivalents thereof as well as additional itemsand equivalents thereof. The use of the terms “mounted,” “connected,”“coupled,” “positioned,” “engaged” and similar terms, is meant toinclude both direct and indirect mounting, connecting, coupling,positioning and engaging.

Computing Architecture

Computer software, hardware, and networks may be utilized in a varietyof different system environments, including standalone, networked,remote-access (aka, remote desktop), virtualized, and/or cloud-basedenvironments, among others. FIG. 1 illustrates one example of a systemarchitecture and data processing device that may be used to implementone or more illustrative aspects described herein in a standalone and/ornetworked environment. Various network nodes 103, 105, 107, and 109 maybe interconnected via a wide area network (WAN) 101, such as theInternet. Other networks may also or alternatively be used, includingprivate intranets, corporate networks, LANs, metropolitan area networks(MAN) wireless networks, personal networks (PAN), and the like. Network101 is for illustration purposes and may be replaced with fewer oradditional computer networks. A local area network (LAN) may have one ormore of any known LAN topology and may use one or more of a variety ofdifferent protocols, such as Ethernet. Devices 103, 105, 107, 109 andother devices (not shown) may be connected to one or more of thenetworks via twisted pair wires, coaxial cable, fiber optics, radiowaves or other communication media.

The term “network” as used herein and depicted in the drawings refersnot only to systems in which remote storage devices are coupled togethervia one or more communication paths, but also to stand-alone devicesthat may be coupled, from time to time, to such systems that havestorage capability. Consequently, the term “network” includes not only a“physical network” but also a “content network,” which is comprised ofthe data—attributable to a single entity—which resides across allphysical networks.

The components may include data server 103, web server 105, and clientcomputers 107, 109. Data server 103 provides overall access, control andadministration of databases and control software for performing one ormore illustrative aspects describe herein. Data server 103 may beconnected to web server 105 through which users interact with and obtaindata as requested. Alternatively, data server 103 may act as a webserver itself and be directly connected to the Internet. Data server 103may be connected to web server 105 through the network 101 (e.g., theInternet), via direct or indirect connection, or via some other network.Users may interact with the data server 103 using remote computers 107,109, e.g., using a web browser to connect to the data server 103 via oneor more externally exposed web sites hosted by web server 105. Clientcomputers 107, 109 may be used in concert with data server 103 to accessdata stored therein, or may be used for other purposes. For example,from client device 107 a user may access web server 105 using anInternet browser, as is known in the art, or by executing a softwareapplication that communicates with web server 105 and/or data server 103over a computer network (such as the Internet).

Servers and applications may be combined on the same physical machines,and retain separate virtual or logical addresses, or may reside onseparate physical machines. FIG. 1 illustrates just one example of anetwork architecture that may be used, and those of skill in the artwill appreciate that the specific network architecture and dataprocessing devices used may vary, and are secondary to the functionalitythat they provide, as further described herein. For example, servicesprovided by web server 105 and data server 103 may be combined on asingle server.

Each component 103, 105, 107, 109 may be any type of known computer,server, or data processing device. Data server 103, e.g., may include aprocessor 111 controlling overall operation of the rate server 103. Dataserver 103 may further include random access memory (RAM) 113, read onlymemory (ROM) 115, network interface 117, input/output interfaces 119(e.g., keyboard, mouse, display, printer, etc.), and memory 121.Input/output (I/O) 119 may include a variety of interface units anddrives for reading, writing, displaying, and/or printing data or files.Memory 121 may further store operating system software 123 forcontrolling overall operation of the data processing device 103, controllogic 125 for instructing data server 103 to perform aspects describedherein, and other application software 127 providing secondary, support,and/or other functionality which may or might not be used in conjunctionwith aspects described herein. The control logic may also be referred toherein as the data server software 125. Functionality of the data serversoftware may refer to operations or decisions made automatically basedon rules coded into the control logic, made manually by a user providinginput into the system, and/or a combination of automatic processingbased on user input (e.g., queries, data updates, etc.).

Memory 121 may also store data used in performance of one or moreaspects described herein, including a first database 129 and a seconddatabase 131. In some embodiments, the first database may include thesecond database (e.g., as a separate table, report, etc.). That is, theinformation can be stored in a single database, or separated intodifferent logical, virtual, or physical databases, depending on systemdesign. Devices 105, 107, 109 may have similar or different architectureas described with respect to device 103. Those of skill in the art willappreciate that the functionality of data processing device 103 (ordevice 105, 107, 109) as described herein may be spread across multipledata processing devices, for example, to distribute processing loadacross multiple computers, to segregate transactions based on geographiclocation, user access level, quality of service (QoS), etc.

One or more aspects may be embodied in computer-usable or readable dataand/or computer-executable instructions, such as in one or more programmodules, executed by one or more computers or other devices as describedherein. Generally, program modules include routines, programs, objects,components, data structures, etc. that perform particular tasks orimplement particular abstract data types when executed by a processor ina computer or other device. The modules may be written in a source codeprogramming language that is subsequently compiled for execution, or maybe written in a scripting language such as (but not limited to)HyperText Markup Language (HTML) or Extensible Markup Language (XML).The computer executable instructions may be stored on a computerreadable medium such as a nonvolatile storage device. Any suitablecomputer readable storage media may be utilized, including hard disks,CD-ROMs, optical storage devices, magnetic storage devices, and/or anycombination thereof. In addition, various transmission (non-storage)media representing data or events as described herein may be transferredbetween a source and a destination in the form of electromagnetic wavestraveling through signal-conducting media such as metal wires, opticalfibers, and/or wireless transmission media (e.g., air and/or space).Various aspects described herein may be embodied as a method, a dataprocessing system, or a computer program product. Therefore, variousfunctionalities may be embodied in whole or in part in software,firmware and/or hardware or hardware equivalents such as integratedcircuits, field programmable gate arrays (FPGA), and the like.Particular data structures may be used to more effectively implement oneor more aspects described herein, and such data structures arecontemplated within the scope of computer executable instructions andcomputer-usable data described herein.

With further reference to FIG. 2, one or more aspects described hereinmay be implemented in a remote-access environment. FIG. 2 depicts anexample system architecture including a generic computing device 201 inan illustrative computing environment 200 that may be used according toone or more illustrative aspects described herein. Generic computingdevice 201 may be used as a server 206 a in a single-server ormulti-server desktop virtualization system (e.g., a remote access orcloud system) configured to provide virtual machines for client accessdevices. The generic computing device 201 may have a processor 203 forcontrolling overall operation of the server and its associatedcomponents, including RAM 205, ROM 207, I/O module 209, and memory 215.

I/O module 209 may include a mouse, keypad, touch screen, scanner,optical reader, and/or stylus (or other input device(s)) through which auser of generic computing device 201 may provide input, and may alsoinclude one or more of a speaker for providing audio output and a videodisplay device for providing textual, audiovisual, and/or graphicaloutput. Software may be stored within memory 215 and/or other storage toprovide instructions to processor 203 for configuring generic computingdevice 201 into a special purpose computing device in order to performvarious functions as described herein. For example, memory 215 may storesoftware used by the computing device 201, such as an operating system217, application programs 219, and an associated database 221.

Computing device 201 may operate in a networked environment supportingconnections to one or more remote computers, such as terminals 240 (alsoreferred to as client devices). The terminals 240 may be personalcomputers, mobile devices, laptop computers, tablets, or servers thatinclude many or all of the elements described above with respect to thegeneric computing device 103 or 201. The network connections depicted inFIG. 2 include a local area network (LAN) 225 and a wide area network(WAN) 229, but may also include other networks. When used in a LANnetworking environment, computing device 201 may be connected to the LAN225 through a network interface or adapter 223. When used in a WANnetworking environment, computing device 201 may include a modem 227 orother wide area network interface for establishing communications overthe WAN 229, such as computer network 230 (e.g., the Internet). It willbe appreciated that the network connections shown are illustrative andother means of establishing a communications link between the computersmay be used. Computing device 201 and/or terminals 240 may also bemobile terminals (e.g., mobile phones, smartphones, personal digitalassistants (PDAs), notebooks, etc.) including various other components,such as a battery, speaker, and antennas (not shown).

Aspects described herein may also be operational with numerous othergeneral purpose or special purpose computing system environments orconfigurations. Examples of other computing systems, environments,and/or configurations that may be suitable for use with aspectsdescribed herein include, but are not limited to, personal computers,server computers, hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set top boxes, programmable consumerelectronics, network personal computers (PCs), minicomputers, mainframecomputers, distributed computing environments that include any of theabove systems or devices, and the like.

As shown in FIG. 2, one or more client devices 240 may be incommunication with one or more servers 206 a-206 n (generally referredto herein as “server(s) 206”). In one embodiment, the computingenvironment 200 may include a network appliance installed between theserver(s) 206 and client machine(s) 240. The network appliance maymanage client/server connections, and in some cases can load balanceclient connections amongst a plurality of backend servers 206.

The client machine(s) 240 may in some embodiments be referred to as asingle client machine 240 or a single group of client machines 240,while server(s) 206 may be referred to as a single server 206 or asingle group of servers 206. In one embodiment a single client machine240 communicates with more than one server 206, while in anotherembodiment a single server 206 communicates with more than one clientmachine 240. In yet another embodiment, a single client machine 240communicates with a single server 206.

A client machine 240 can, in some embodiments, be referenced by any oneof the following non-exhaustive terms: client machine(s); client(s);client computer(s); client device(s); client computing device(s); localmachine; remote machine; client node(s); endpoint(s); or endpointnode(s). The server 206, in some embodiments, may be referenced by anyone of the following non-exhaustive terms: server(s), local machine;remote machine; server farm(s), or host computing device(s).

In one embodiment, the client machine 240 may be a virtual machine. Thevirtual machine may be any virtual machine, while in some embodimentsthe virtual machine may be any virtual machine managed by a Type 1 orType 2 hypervisor, for example, a hypervisor developed by CitrixSystems, IBM, VMware, or any other hypervisor. In some aspects, thevirtual machine may be managed by a hypervisor, while in aspects thevirtual machine may be managed by a hypervisor executing on a server 206or a hypervisor executing on a client 240.

Some embodiments include a client device 240 that displays applicationoutput generated by an application remotely executing on a server 206 orother remotely located machine. In these embodiments, the client device240 may execute a virtual machine receiver program or application todisplay the output in an application window, a browser, or other outputwindow. In one example, the application is a desktop, while in otherexamples the application is an application that generates or presents adesktop. A desktop may include a graphical shell providing a userinterface for an instance of an operating system in which local and/orremote applications can be integrated. Applications, as used herein, areprograms that execute after an instance of an operating system (and,optionally, also the desktop) has been loaded.

The server 206, in some embodiments, uses a remote presentation protocolor other program to send data to a thin-client or remote-displayapplication executing on the client to present display output generatedby an application executing on the server 206. The thin-client orremote-display protocol can be any one of the following non-exhaustivelist of protocols: the Independent Computing Architecture (ICA) protocoldeveloped by Citrix Systems, Inc. of Ft. Lauderdale, Fla.; or the RemoteDesktop Protocol (RDP) manufactured by the Microsoft Corporation ofRedmond, Wash.

A remote computing environment may include more than one server 206a-206 n such that the servers 206 a-206 n are logically grouped togetherinto a server farm 206, for example, in a cloud computing environment.The server farm 206 may include servers 206 that are geographicallydispersed while and logically grouped together, or servers 206 that arelocated proximate to each other while logically grouped together.Geographically dispersed servers 206 a-206 n within a server farm 206can, in some embodiments, communicate using a WAN (wide), MAN(metropolitan), or LAN (local), where different geographic regions canbe characterized as: different continents; different regions of acontinent; different countries; different states; different cities;different campuses; different rooms; or any combination of the precedinggeographical locations. In some embodiments the server farm 206 may beadministered as a single entity, while in other embodiments the serverfarm 206 can include multiple server farms.

In some embodiments, a server farm may include servers 206 that executea substantially similar type of operating system platform (e.g.,WINDOWS, UNIX, LINUX, iOS, ANDROID, SYMBIAN, etc.) In other embodiments,server farm 206 may include a first group of one or more servers thatexecute a first type of operating system platform, and a second group ofone or more servers that execute a second type of operating systemplatform.

Server 206 may be configured as any type of server, as needed, e.g., afile server, an application server, a web server, a proxy server, anappliance, a network appliance, a gateway, an application gateway, agateway server, a virtualization server, a deployment server, a SecureSockets Layer (SSL) VPN server, a firewall, a web server, an applicationserver or as a master application server, a server executing an activedirectory, or a server executing an application acceleration programthat provides firewall functionality, application functionality, or loadbalancing functionality. Other server types may also be used.

Some embodiments include a first server 106 a that receives requestsfrom a client machine 240, forwards the request to a second server 106b, and responds to the request generated by the client machine 240 witha response from the second server 106 b. First server 106 a may acquirean enumeration of applications available to the client machine 240 andwell as address information associated with an application server 206hosting an application identified within the enumeration ofapplications. First server 106 a can then present a response to theclient's request using a web interface, and communicate directly withthe client 240 to provide the client 240 with access to an identifiedapplication. One or more clients 240 and/or one or more servers 206 maytransmit data over network 230, e.g., network 101.

FIG. 2 shows a high-level architecture of an illustrative desktopvirtualization system. As shown, the desktop virtualization system maybe single-server or multi-server system, or cloud system, including atleast one virtualization server 206 configured to provide virtualdesktops and/or virtual applications to one or more client accessdevices 240. As used herein, a desktop refers to a graphical environmentor space in which one or more applications may be hosted and/orexecuted. A desktop may include a graphical shell providing a userinterface for an instance of an operating system in which local and/orremote applications can be integrated. Applications may include programsthat execute after an instance of an operating system (and, optionally,also the desktop) has been loaded. Each instance of the operating systemmay be physical (e.g., one operating system per device) or virtual(e.g., many instances of an OS running on a single device). Eachapplication may be executed on a local device, or executed on a remotelylocated device (e.g., remoted).

With further reference to FIG. 3, a computer device 301 may beconfigured as a virtualization server in a virtualization environment,for example, a single-server, multi-server, or cloud computingenvironment. Virtualization server 301 illustrated in FIG. 3 can bedeployed as and/or implemented by one or more embodiments of the server206 illustrated in FIG. 2 or by other known computing devices. Includedin virtualization server 301 is a hardware layer that can include one ormore physical disks 304, one or more physical devices 306, one or morephysical processors 308 and one or more physical memories 316. In someembodiments, firmware 312 can be stored within a memory element in thephysical memory 316 and can be executed by one or more of the physicalprocessors 308. Virtualization server 301 may further include anoperating system 314 that may be stored in a memory element in thephysical memory 316 and executed by one or more of the physicalprocessors 308. Still further, a hypervisor 302 may be stored in amemory element in the physical memory 316 and can be executed by one ormore of the physical processors 308.

Executing on one or more of the physical processors 308 may be one ormore virtual machines 332A-C (generally 332). Each virtual machine 332may have a virtual disk 326A-C and a virtual processor 328A-C. In someembodiments, a first virtual machine 332A may execute, using a virtualprocessor 328A, a control program 320 that includes a tools stack 324.Control program 320 may be referred to as a control virtual machine,Dom0, Domain 0, or other virtual machine used for system administrationand/or control. In some embodiments, one or more virtual machines 332B-Ccan execute, using a virtual processor 328B-C, a guest operating system330A-B.

Virtualization server 301 may include a hardware layer 310 with one ormore pieces of hardware that communicate with the virtualization server301. In some embodiments, the hardware layer 310 can include one or morephysical disks 304, one or more physical devices 306, one or morephysical processors 308, and one or more memory 216. Physical components304, 306, 308, and 316 may include, for example, any of the componentsdescribed above. Physical devices 306 may include, for example, anetwork interface card, a video card, a keyboard, a mouse, an inputdevice, a monitor, a display device, speakers, an optical drive, astorage device, a universal serial bus connection, a printer, a scanner,a network element (e.g., router, firewall, network address translator,load balancer, virtual private network (VPN) gateway, Dynamic HostConfiguration Protocol (DHCP) router, etc.), or any device connected toor communicating with virtualization server 301. Physical memory 316 inthe hardware layer 310 may include any type of memory. Physical memory316 may store data, and in some embodiments may store one or moreprograms, or set of executable instructions. FIG. 3 illustrates anembodiment where firmware 312 is stored within the physical memory 316of virtualization server 301. Programs or executable instructions storedin the physical memory 316 can be executed by the one or more processors308 of virtualization server 301.

Virtualization server 301 may also include a hypervisor 302. In someembodiments, hypervisor 302 may be a program executed by processors 308on virtualization server 301 to create and manage any number of virtualmachines 332. Hypervisor 302 may be referred to as a virtual machinemonitor, or platform virtualization software. In some embodiments,hypervisor 302 can be any combination of executable instructions andhardware that monitors virtual machines executing on a computingmachine. Hypervisor 302 may be Type 2 hypervisor, where the hypervisorthat executes within an operating system 314 executing on thevirtualization server 301. Virtual machines then execute at a levelabove the hypervisor. In some embodiments, the Type 2 hypervisorexecutes within the context of a user's operating system such that theType 2 hypervisor interacts with the user's operating system. In otherembodiments, one or more virtualization servers 201 in a virtualizationenvironment may instead include a Type 1 hypervisor (not shown). A Type1 hypervisor may execute on the virtualization server 301 by directlyaccessing the hardware and resources within the hardware layer 310. Thatis, while a Type 2 hypervisor 302 accesses system resources through ahost operating system 314, as shown, a Type 1 hypervisor may directlyaccess all system resources without the host operating system 314. AType 1 hypervisor may execute directly on one or more physicalprocessors 308 of virtualization server 301, and may include programdata stored in the physical memory 316.

Hypervisor 302, in some embodiments, can provide virtual resources tooperating systems 330 or control programs 320 executing on virtualmachines 332 in any manner that simulates the operating systems 330 orcontrol programs 320 having direct access to system resources. Systemresources can include, but are not limited to, physical devices 306,physical disks 304, physical processors 308, physical memory 316 and anyother component included in virtualization server 301 hardware layer310. Hypervisor 302 may be used to emulate virtual hardware, partitionphysical hardware, virtualize physical hardware, and/or execute virtualmachines that provide access to computing environments. In still otherembodiments, hypervisor 302 controls processor scheduling and memorypartitioning for a virtual machine 332 executing on virtualizationserver 301. Hypervisor 302 may include those manufactured by VMWare,Inc., of Palo Alto, Calif.; the XEN hypervisor, an open source productwhose development is overseen by the open source Xen.org community;HyperV, VirtualServer or virtual PC hypervisors provided by Microsoft,or others. In some embodiments, virtualization server 301 executes ahypervisor 302 that creates a virtual machine platform on which guestoperating systems may execute. In these embodiments, the virtualizationserver 301 may be referred to as a host server. An example of such avirtualization server is the XEN SERVER provided by Citrix Systems,Inc., of Fort Lauderdale, Fla.

Hypervisor 302 may create one or more virtual machines 332B-C (generally332) in which guest operating systems 330 execute. In some embodiments,hypervisor 302 may load a virtual machine image to create a virtualmachine 332. In other embodiments, the hypervisor 302 may executes aguest operating system 330 within virtual machine 332. In still otherembodiments, virtual machine 332 may execute guest operating system 330.

In addition to creating virtual machines 332, hypervisor 302 may controlthe execution of at least one virtual machine 332. In other embodiments,hypervisor 302 may presents at least one virtual machine 332 with anabstraction of at least one hardware resource provided by thevirtualization server 301 (e.g., any hardware resource available withinthe hardware layer 310). In other embodiments, hypervisor 302 maycontrol the manner in which virtual machines 332 access physicalprocessors 308 available in virtualization server 301. Controllingaccess to physical processors 308 may include determining whether avirtual machine 332 should have access to a processor 308, and howphysical processor capabilities are presented to the virtual machine332.

As shown in FIG. 3, virtualization server 301 may host or execute one ormore virtual machines 332. A virtual machine 332 is a set of executableinstructions that, when executed by a processor 308, imitate theoperation of a physical computer such that the virtual machine 332 canexecute programs and processes much like a physical computing device.While FIG. 3 illustrates an embodiment where a virtualization server 301hosts three virtual machines 332, in other embodiments virtualizationserver 301 can host any number of virtual machines 332. Hypervisor 302,in some embodiments, provides each virtual machine 332 with a uniquevirtual view of the physical hardware, memory, processor and othersystem resources available to that virtual machine 332. In someembodiments, the unique virtual view can be based on one or more ofvirtual machine permissions, application of a policy engine to one ormore virtual machine identifiers, a user accessing a virtual machine,the applications executing on a virtual machine, networks accessed by avirtual machine, or any other desired criteria. For instance, hypervisor302 may create one or more unsecure virtual machines 332 and one or moresecure virtual machines 332. Unsecure virtual machines 332 may beprevented from accessing resources, hardware, memory locations, andprograms that secure virtual machines 332 may be permitted to access. Inother embodiments, hypervisor 302 may provide each virtual machine 332with a substantially similar virtual view of the physical hardware,memory, processor and other system resources available to the virtualmachines 332.

Each virtual machine 332 may include a virtual disk 326A-C (generally326) and a virtual processor 328A-C (generally 328.) The virtual disk326, in some embodiments, is a virtualized view of one or more physicaldisks 304 of the virtualization server 301, or a portion of one or morephysical disks 304 of the virtualization server 301. The virtualizedview of the physical disks 304 can be generated, provided and managed bythe hypervisor 302. In some embodiments, hypervisor 302 provides eachvirtual machine 332 with a unique view of the physical disks 304. Thus,in these embodiments, the particular virtual disk 326 included in eachvirtual machine 332 can be unique when compared with the other virtualdisks 326.

A virtual processor 328 can be a virtualized view of one or morephysical processors 308 of the virtualization server 301. In someembodiments, the virtualized view of the physical processors 308 can begenerated, provided and managed by hypervisor 302. In some embodiments,virtual processor 328 has substantially all of the same characteristicsof at least one physical processor 308. In other embodiments, virtualprocessor 308 provides a modified view of physical processors 308 suchthat at least some of the characteristics of the virtual processor 328are different than the characteristics of the corresponding physicalprocessor 308.

With further reference to FIG. 4, some aspects described herein may beimplemented in a cloud-based environment. FIG. 4 illustrates an exampleof a cloud computing environment (or cloud system) 400. As seen in FIG.4, client computers 411-414 may communicate with a cloud managementserver 410 to access the computing resources (e.g., host servers 403,storage resources 404, and network resources 405) of the cloud system.

Management server 410 may be implemented on one or more physicalservers. The management server 410 may run, for example, CLOUDSTACK byCitrix Systems, Inc. of Ft. Lauderdale, Fla., or OPENSTACK, amongothers. Management server 410 may manage various computing resources,including cloud hardware and software resources, for example, hostcomputers 403, data storage devices 404, and networking devices 405. Thecloud hardware and software resources may include private and/or publiccomponents. For example, a cloud may be configured as a private cloud tobe used by one or more particular customers or client computers 411-414and/or over a private network. In other embodiments, public clouds orhybrid public-private clouds may be used by other customers over an openor hybrid networks.

Management server 410 may be configured to provide user interfacesthrough which cloud operators and cloud customers may interact with thecloud system. For example, the management server 410 may provide a setof application programming interfaces (APIs) and/or one or more cloudoperator console applications (e.g., web-based on standaloneapplications) with user interfaces to allow cloud operators to managethe cloud resources, configure the virtualization layer, manage customeraccounts, and perform other cloud administration tasks. The managementserver 410 also may include a set of APIs and/or one or more customerconsole applications with user interfaces configured to receive cloudcomputing requests from end users via client computers 411-414, forexample, requests to create, modify, or destroy virtual machines withinthe cloud. Client computers 411-414 may connect to management server 410via the Internet or other communication network, and may request accessto one or more of the computing resources managed by management server410. In response to client requests, the management server 410 mayinclude a resource manager configured to select and provision physicalresources in the hardware layer of the cloud system based on the clientrequests. For example, the management server 410 and additionalcomponents of the cloud system may be configured to provision, create,and manage virtual machines and their operating environments (e.g.,hypervisors, storage resources, services offered by the networkelements, etc.) for customers at client computers 411-414, over anetwork (e.g., the Internet), providing customers with computationalresources, data storage services, networking capabilities, and computerplatform and application support. Cloud systems also may be configuredto provide various specific services, including security systems,development environments, user interfaces, and the like.

Certain clients 411-414 may be related, for example, different clientcomputers creating virtual machines on behalf of the same end user, ordifferent users affiliated with the same company or organization. Inother examples, certain clients 411-414 may be unrelated, such as usersaffiliated with different companies or organizations. For unrelatedclients, information on the virtual machines or storage of any one usermay be hidden from other users.

Referring now to the physical hardware layer of a cloud computingenvironment, availability zones 401-402 (or zones) may refer to acollocated set of physical computing resources. Zones may begeographically separated from other zones in the overall cloud ofcomputing resources. For example, zone 401 may be a first clouddatacenter located in California, and zone 402 may be a second clouddatacenter located in Florida. Management sever 410 may be located atone of the availability zones, or at a separate location. Each zone mayinclude an internal network that interfaces with devices that areoutside of the zone, such as the management server 410, through agateway. End users of the cloud (e.g., clients 411-414) might or mightnot be aware of the distinctions between zones. For example, an end usermay request the creation of a virtual machine having a specified amountof memory, processing power, and network capabilities. The managementserver 410 may respond to the user's request and may allocate theresources to create the virtual machine without the user knowing whetherthe virtual machine was created using resources from zone 401 or zone402. In other examples, the cloud system may allow end users to requestthat virtual machines (or other cloud resources) are allocated in aspecific zone or on specific resources 403-405 within a zone.

In this example, each zone 401-402 may include an arrangement of variousphysical hardware components (or computing resources) 403-405, forexample, physical hosting resources (or processing resources), physicalnetwork resources, physical storage resources, switches, and additionalhardware resources that may be used to provide cloud computing servicesto customers. The physical hosting resources in a cloud zone 401-402 mayinclude one or more computer servers 403, such as the virtualizationservers 301 described above, which may be configured to create and hostvirtual machine instances. The physical network resources in a cloudzone 401 or 402 may include one or more network elements 405 (e.g.,network service providers) comprising hardware and/or softwareconfigured to provide a network service to cloud customers, such asfirewalls, network address translators, load balancers, virtual privatenetwork (VPN) gateways, Dynamic Host Configuration Protocol (DHCP)routers, and the like. The storage resources in the cloud zone 401-402may include storage disks (e.g., solid state drives (SSDs), magnetichard disks, etc.) and other storage devices.

The example cloud computing environment shown in FIG. 4 also may includea virtualization layer (e.g., as shown in FIGS. 1-3) with additionalhardware and/or software resources configured to create and managevirtual machines and provide other services to customers using thephysical resources in the cloud. The virtualization layer may includehypervisors, as described above in FIG. 3, along with other componentsto provide network virtualizations, storage virtualizations, etc. Thevirtualization layer may be as a separate layer from the physicalresource layer, or may share some or all of the same hardware and/orsoftware resources with the physical resource layer. For example, thevirtualization layer may include a hypervisor installed in each of thevirtualization servers 403 with the physical computing resources. Knowncloud systems may alternatively be used, e.g., WINDOWS AZURE (MicrosoftCorporation of Redmond Washington), AMAZON EC2 (Amazon.com Inc. ofSeattle, Wash.), IBM BLUE CLOUD (IBM Corporation of Armonk, N.Y.), orothers.

Cross-Domain Proxy Architecture

FIG. 5 illustrates a prior art system architecture where all virtualizeddesktop applications (VDAs), desktop delivery controllers (DDCs), andthe primary domain controller (PDC) are all resident on-premises at auser's location. Because all resources are located at the user location,each user incurs significant cost associated with purchasing hardwareand software resources, as well as employee time and salary to maintainthe system.

FIG. 6 depicts an illustrative system architecture for a cross-domainproxy according to one or more illustrative aspects described herein. Inthe system architecture 600 of FIG. 6, the DDCs may be placed in acloud-based environment, e.g., as illustrated with respect to FIG. 4.Customers and users can realize significant cost savings by moving DDCsto a cloud-based system using economies of scale realized bycloud-architectures. However, because of inherent security measuresenforced by each system's primary domain controller (PDC), the move isnot as simple as just installing the software in a different location.Rather, each DDC and VDA expect to be installed on the same primarydomain to ensure that necessary security measures are enforced. As aresult, aspects described herein provide techniques for communicatinginformation between domains, while each party to the transactionbelieves it is on the same domain as the other party to the transaction.

Aspects described herein adhere to the following limitations orrestrictions. The base brokering protocol should not be modified, sothat the same protocol can be used regardless of whether the systemarchitecture is as shown in FIG. 5 or FIG. 6. The VDAs and the brokerdatabase should not be modified for the same reason. There should beminimal impact on the broker, and preferably no impact on the brokercore logic. The solution should account for the fact that WindowsCommunication Foundation (WCF) Kerberos authentication does not workwhen VDAs and brokers are in separate domains, nor do VDA and broker IPaddresses because each expects a local domain IP address. In order tomaintain proper security measures, both the on-premises and in-clouddomains should communicate without using an external public IP address(e.g., to prevent third-party attacks). A protocol or othercommunication technique that is dependent on each party to a transactionbeing resident within the same domain is referred to herein as anintra-domain protocol or intra-domain communication. A protocol thatcommunicates between two different domains is said to be an inter-domainprotocol or communication.

As a general introduction to a more detailed description that follows,the system architecture of FIG. 6 allows users to save costs andresources while making the VDAs perceive the broker as beingon-premises, and the broker perceives the VDAs as being “in the cloud.”As a result, each perceives the other as local to itself, through theuse of a proxy module at each location.

The broker proxy 601 may be installed on a dedicated Windows machine ona customer premises. Broker proxy 601 exposes the broker's WCFcontroller interface through which each VDA communicates. Each VDA isdirected to the broker proxy 601, and sends all WCF calls to brokerproxy 601. Because both the broker proxy 601 and each VDA 602 arelocated in the same domain, the WCF Kerberos authentication workswithout further modification. The broker proxy may also authenticate VDAWCF incoming calls, e.g., using the same test as the actual Broker (DDC)performs. The broker proxy may also change broker supplied WCF Endpointsto reference the Broker Proxy instead of the Broker (e.g., ITicketing,INotify). The broker proxy will reconstruct calls from the VDA Proxy forcalls to an actual VDA.

The broker proxy may also optimize registration by performing the Testcall locally. Registration proceeds when the Test succeeds. Registrationis stopped when the Test fails. This eliminates the need for a Test callover Azure Service Bus (ASB) or other custom transport (e.g., a longdistance transport service providing enhanced speed and security, whichcan mock CBP and related information, and that does not require theopening of firewall ports).

The VDA proxy 602 may be installed on a machine at the cloud location,e.g., the same machine as the broker(s), in order to reduce cost. EachDDC may incorporate a brokering management module as well as otherservice modules (e.g., licensing, provisioning, storefront). VDA proxy602 exposes the VDA's WCF worker interface allowing the broker todirectly communicate with it. VDA Proxy 602 may also perform loadbalancing when communicating with multiple brokers (DDCs), e.g., duringregistration. Because both the VDA proxy 602 and each of the brokers arein the same domain, WCF Kerberos authentication works on this side aswell. Other types of authentication may be used based on the type ofauthentication in use. The VDA proxy may also discover DDCs via theregistry ListOfDDCs (same as may be used by the VDA). The VDA proxy mayroute WCF calls to the correct DDC (notifications, validate connection .. . ), maintain a dictionary or database of registered VDAs andRegistered DDCs, maintain a record of Last Heartbeat timestamp(s),authenticate DDC WCF incoming calls (must originate from known DDC),forwards VDA metadata to Broker Proxy, reconstructs calls from BrokerProxy for calls to a broker, and optimizes registration by alwaysreturning success for the Test call.

Broker proxy 601 and VDA proxy 602 act as forwarding agents for theprotocol in use between the VDAs and the DDCs. In one embodiment, CitrixBrokering Protocol (CBP) may be used. A similar architecture and aspectsdescribed herein are also usable with other protocols and systems. Asingle Microsoft Azure Service Bus (ASB) may be used for communicationsbetween different domains, because ASB does not require Kerberosauthentication nor external IP addresses or a custom transport also notrequiring Kerberos authentication. Each VDA makes brokering calls (e.g.,using the brokering protocol in use) to broker proxy 601 via WCF, whichforwards the calls over ASB or custom transport to VDA proxy 602, whichin turn forwards the calls via WCF to the broker/DDC. The VDA is unawareof the hops from its local on-premises domain to the broker's in-clouddomain.

VDA calls to the broker may be routed to a randomly selected broker whenthe VDA call is for initial registration according to the protocol inuse. The registration process may inform the broker of the VDA's WCFendpoints including the VDA's on-premises IP address, which are saved inthe broker database. VDA calls may be routed to the broker with whichthe VDA is registered for all other calls according to the protocol inuse. Alternatively, in order to provide High Availability service,successive calls may be routed to a randomly selected DDC as is done forregistration.

The broker responds by making its own calls to VDA proxy 602 via WCF,which forwards the calls over ASB back to broker proxy 601, which inturn forwards the calls via WCF to the applicable VDA. The broker isunaware of the hops from its local in-cloud domain to the VDA'son-premises domain. Broker calls may be made only to registered VDAsidentifying the VDA using an IP address. Because the IP address is notvalid in the in-cloud domain, the IP address and related contractinformation (e.g., WCF bindings, contract name, etc.) may be packaged inthe WCF transport header as metadata or similar metadata feature of thecustom transport. This metadata is forwarded by VDA proxy 602 to brokerproxy 601, which extracts the metadata, rebuilds the WCF call from theprovided IP address and contract information, and calls the VDA via WCFon-premises. The original protocol request and replies are transportedunchanged, and all protocol calls can remain synchronous by following astandard request-reply model.

Using aspects described herein, multiple VDAs can communicate tomultiple DDCs over a single Azure Service Bus (ASB) or custom transport.Load balancing can be performed in the system, whereas VDAs individuallyhandled load balancing previously. Each VDA is able to select a DDC evenwhen it cannot directly communicate with it. Load balancing may beperformed by the Azure Service Bus or custom transport between multipleVDA proxies.

According to an illustrative aspect, a WCF endpoint and related info (asmetadata) are added to the message header using the WCFOperationalContextScope feature or similar metadata feature of thecustom transport. The original protocol request is transported withadditional metadata across the ASB or custom transport. The receivingproxy on the other end uses the metadata to reconstruct the actualendpoint, and call the actual endpoint at that location.

An OperationalContextScope Send-Sample is reproduced in FIG. 7. FIG. 7represents a request from the Broker to the VDA to prepare for a newconnection to the VDA from a client. The first three added header valuesare the 3 pieces of WCF contract information (address, binding, andcontract). The next is the actual VDA IP address, the VDA DNS name andthe following values are for tracing/debugging. A custom transport sendsthe same metadata using its own custom method.

An OperationalContext Receive-Sample: part A, is reproduced in FIG. 8.FIG. 8 represents the Broker Proxy receiving a call from the cloud. Thebroker proxy extracts the WCF binding, address and contract informationso the broker proxy can reconstruct the new endpoint to the VDA. Thebroker proxy finishes by creating the actual WCF channel to the VDA.

An OperationalContext Receive-Sample: part B, is reproduced in FIG. 9,showing how the metadata is extracted from the WCF header. A customtransport may use its own method to extract the same metadata.

When sending messages from a broker to the VDA proxy, and then to thebroker proxy, the following metadata may be included in each messageheader from the VDA proxy to the broker proxy: 1) VDA Endpoint Binding,Used to create VDA WCF connection; 2) VDA Endpoint Address—Used tocreate VDA WCF connection; 3) VDA Endpoint Contract—Used to create VDAWCF connection; 4) VDA IP Address—Used to create VDA WCF connection; 5)VDA DNS Name—Used in tracing; 6) Time Sent—Used to calculate one-way ASBlatency; 7) Calling DDC DNS name—Used in tracing.

When sending messages from a VDA to the broker proxy, and then to theVDA proxy, the following metadata may be included in the head of eachmessage from the broker proxy to the VDA proxy: 1) VDA SID—Used forBroker VDA Authentication; 2) VDA IP—Used to create VDA WCF connection;3) VDA To—DDC target endpoint, used to rebuild actual DDC endpoint; 4)Time Sent—Used to calculate one-way ASB latency; 5) Proxy InstanceID—Reserved for future use.

When each VDA communicates with the broker proxy, no code or binarychanges are made to use RTM VDA. The VDA ListOfDDCs points to On-PremBroker Proxy(s). In addition, the Farm-GUID site discovery might not besupported. That is, Farm-GUID is a legacy site-discovery method and isnot commonly used (but could be if desired). Auto-List-Of-DDCs is a morerobust site-discovery method that improves the registration process.With the current development of multi-geo support the Auto-List-Of-DDCsmethod is preferred, but not exclusive.

Existing broker core login may be changed as follows, or in a similarmanner to achieve a similar result:

a. Created MEF loaded WCF Factory Class

b. Core functions (current functionality), loaded by default

c. Proxy functions, loaded by app.config file appSettings value

d. Refactored explicit WCF Close and Abort calls to WCF Factory Classmethods

e. Provides method to cleanly wrap Operational Context Scope aroundexisting WCF calls to the VDA

f. Refactored Authentication calls to WCF Factory Class for necessarycustomization

g. AuthenticateWorkerSid from Registrar.cs

h. AuthenticateUserSid from NotifyBroker.cs

i. All WCF related functions are now in WCF Factory class and not spreadthroughout the Broker

j. The core Broker function is unaware of the proxy's presence

k. Proxy WCF Factory Class calls the Core WCF Factory Class; channelcreation functions are not duplicated

According to an illustrative aspect, the VDA proxy and broker proxy bothimplement Worker and Controller Interfaces. WCF binding type may becontrolled via a config file. wsHttpBinding may be provided for Proxy toBroker and Broker Agent. netTcpRelayBinding (ASB) or a custom transportmay be provided for Proxy to Proxy communications. Proxy differentiationis in how WCF calls are forwarded. As a result, there is onelight-weight service with a ‘personality’ forwarding plugin controlledby a VDA or Broker Proxy unique app.config file. One service means oneMSI; install parameter determines Proxy Type. Logging may be done via adiagnostics facility, e.g., Citrix Diagnostic Facility (CDF).

FIG. 10 illustrates a detailed schematic of a portion of the proxyarchitecture depicted in FIG. 6.

Various authorizations may be used by the proxy modules. The brokerproxy verifies a caller is a valid VDA by comparing the VDA SID(security ID) in the Request's Connection ID with SID in the WCFoperational context (same test as the actual broker would perform). TheVDA Proxy verifies each caller is a valid DDC by comparing the SIDderived from ListOfDDCs with the SID in the WCF operational context(same test as Broker Agent performs). Each broker may also verify that acaller is the other proxy by comparing the SID derived fromListOfProxies with SID in the WCF operational context. Each broker alsorepeats VDA SID test for confirmation.

According to an illustrative aspect, a heartbeat message is sent fromBroker (DDC) to VDA proxy. A first heartbeat may be sent after 5seconds, and successive heartbeats every 5 minutes. The heartbeat sendsBroker Proxies API metrics, and may be used to detect ASB or customtransport failure. The VDA Proxy logs Broker Proxy API metrics and itsown VDA API metrics. The heartbeat procedures may useICloudCommunincation or similar interface.

The following API metrics may be maintained and analyzed to ensure thehealth and integrity of the proxy system. The metrics provideperformance times for each call type and the overall proxy. Thesemetrics identify performance issues and Azure Service Bus issues andfailures. The use of metrics is not required. However, without metricsit is difficult to identify proxy communication issues other than acomplete failure.

For each protocol call received from the Broker or VDA, the followingmetrics may be tracked/monitored:

a. Total number of calls

b. Total number of aborts

c. Total number of fails

d. Total number of Reply fails

e. Total Round-trip time

f. Minimum Time

g. Maximum Time

h. Average Time

i. Same metrics recorded for overall Proxy

According to another illustrative aspect, unique proxy ASB endpoints maybe used. In addition, an XML services plugin may be used as a generichttp/https listener and forwarder, which may use reflection to discoverXML handlers such as STA and NFuse. The STA handler may be a simpleforwarder. The Nfuse handler may implement encrypted password featuresto extend the Nfuse RequestAddress to send encrypted password and hashedticket.

Using aspects described herein, resources that otherwise need to beco-located on the same administrative domain can be moved to disparatelocations, e.g., using a cloud-based system architecture. Protocolconversion may be performed when the two sites use different brokeringprotocols.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.

What is claimed is:
 1. A system comprising: one or more virtual desktopapplications (VDAs) executing on a first physical computing device andhosted within a customer domain; one or more desktop deliverycontrollers (DDCs) executing on a second physical computing device andhosted within one or more service provider domains different from thecustomer domain, wherein the one or more DDCs are configured to providebroker services to the one or more VDAs; a broker proxy module hostedwithin the customer domain; and a plurality of VDA proxy modules hostedwithin the one or more service provider domains, wherein the brokerproxy module is configured to: receive, from one or more of theplurality of VDA proxy modules, metrics associated with a health of thebroker services; receiving, from the one or more VDAs, a request forbroker services; determine, based on the metrics, a first VDA proxymodule of the plurality of VDA proxy modules; and send, to the first VDAproxy module, the request for broker services, wherein the first VDAproxy module is configured to transmit the request to the one or moreDDCs as if the one or more VDAs and the one or more DDCs were hostedwithin a single domain.
 2. The system of claim 1, wherein the brokerproxy module is configured to send the request by sending the request isvia a network, and wherein the metrics indicate a total round-trip timeassociated with the network.
 3. The system of claim 1, wherein thebroker proxy module is configured to send the request by sending therequest is via a network, and wherein the metrics indicate a totalnumber of calls made via the network.
 4. The system of claim 1, whereinthe broker proxy module is configured to send the request by sending therequest is via a network, and wherein the metrics indicate a failure ofan interface of the network.
 5. The system of claim 1, wherein thebroker proxy module is configured to send the request by sending therequest comprises sending the request via an intra-domain protocol, andwherein the intra-domain protocol is Citrix Brokering Protocol (CBP)over WCF Kerberos.
 6. The system of claim 1, wherein the broker proxymodule executes on the first physical computing device.
 7. The system ofclaim 1, wherein at least one of the plurality of VDA proxy modulesexecutes on the second physical computing device.
 8. A methodcomprising: sending, by a broker proxy module hosted within a customerdomain and to a virtual desktop application (VDA) proxy module hostedwithin one or more service provider domains, a message, wherein the VDAproxy module is configured to provide a service associated with one ormore desktop delivery controllers (DDCs) executing on a second physicalcomputing device and hosted within the one or more service providerdomains; receiving, from the VDA proxy module and in response to themessage, metrics associated with a health of the service; receiving,from a VDA executing on a first physical computing device and hostedwithin the customer domain, a request associated with the service; andsending, based on the metrics and to the VDA proxy module, the request,wherein the VDA proxy module is configured to transmit the request tothe one or more DDCs as if the VDA and the one or more DDCs were hostedwithin a single domain.
 9. The method of claim 8, wherein sending therequest is via a network, and wherein the metrics indicate a totalround-trip time associated with the network.
 10. The method of claim 8,wherein sending the request is via a network, and wherein the metricsindicate a total number of calls made via the network.
 11. The method ofclaim 8, wherein sending the request is via a network, and wherein themetrics indicate a failure of an interface of the network.
 12. Themethod of claim 8, wherein sending the request comprises sending therequest via an intra-domain protocol, and wherein the intra-domainprotocol is Citrix Brokering Protocol (CBP) over WCF Kerberos.
 13. Themethod of claim 8, wherein the broker proxy module executes on the firstphysical computing device.
 14. The method of claim 8, wherein the VDAproxy module executes on the second physical computing device.
 15. Themethod of claim 8, wherein the instructions, when executed by the one ormore processors, cause the computing device to send the request via anetwork, and wherein the metrics indicate a total number of calls madevia the network.
 16. The method of claim 8, wherein the instructions,when executed by the one or more processors, cause the computing deviceto send the request via a network, and wherein the metrics indicate afailure of an interface of the network.
 17. The method of claim 8,wherein the instructions, when executed by the one or more processors,cause the computing device to send the request by causing the computingdevice to send the request via an intra-domain protocol, and wherein theintra-domain protocol is Citrix Brokering Protocol (CBP) over WCFKerberos.
 18. The method of claim 8, wherein the broker proxy moduleexecutes on the computing device.
 19. One or more non-transitorycomputer-readable media storing instructions that, when executed by oneor more processors, cause a computing device to: send, via a brokerproxy module hosted within a customer domain and to a virtual desktopapplication (VDA) proxy module hosted within one or more serviceprovider domains, a message, wherein the VDA proxy module is configuredto provide a service associated with one or more desktop deliverycontrollers (DDCs) executing on a second physical computing device andhosted within the one or more service provider domains; receive, fromthe VDA proxy module and in response to the message, metrics associatedwith a health of the service; receive, from a VDA executing on a firstphysical computing device and hosted within the customer domain, arequest associated with the service; and send, based on the metrics andto the VDA proxy module, the request, wherein the VDA proxy module isconfigured to transmit the request to the one or more DDCs as if the VDAand the one or more DDCs were hosted within a single domain.
 20. Thenon-transitory computer-readable media of claim 19, wherein theinstructions, when executed by the one or more processors, cause thecomputing device to send the request via a network, and wherein themetrics indicate a total round-trip time associated with the network.